'''
The Order Taker User Interface for the coffee bar workflow (Winter Intensives Lab 5)

This is where you define the fields that appear on the screen (application) the order
taker sees and tell WMP how this application (user interface) fits into the overall
workflow.

Note:  the comments here assume you have already read through the comments
in CoffeeBackend.py and made your edits there.
'''

# these next few lines import some of the WMP functions we will
# use in this file.
from frontend.roleApplication import RoleApplication
from frontend.form import Type

class OrderTakerApplication(RoleApplication):
    '''
    The OrderTakerApplication "class" is a collection of the "methods" (functions) that 
    define the elements of the order taker application.  
    
    An application will always include the method __init__ and at least one
    method to define a form that the user of this application will use.
    There could be several different forms, but for this simple workflow there
    is only one form and thus one method:  take_drink_order_form creator.
    
    See the notes for each method to see what you need to do to get this application working.
    '''

    def __init__(self):
        '''
        This __init__ method is called automatically when we run the code in this file.
        
        This __init__ method consists of two lines of code, both of which you will
        need to edit.
        
        The first line of code tells WMP which workflow and role this application is associated with.
        
        The second line of code tells WMP what kind of user interface is needed and where to
        find the code to build that interface.
        
        We will edit each of these lines of code in turn:
        
        Editing the First Line of Code
        ------------------------------
        The first line of code actually calls an __init__ method from another part of the WMP system,
        which does the actual work of recording the workflow name and rolename for this application.  
        
        To fix this line of code you need to replace "WorkflowName" and "RoleName" with the actual
        name you gave your workflow in CoffeeBackend and the actual name you gave the order taker
        role (also in CoffeeBackend).  That way WMP knows where this application (user interface)
        fits into the workflow you have defined.  See the __init__ and wire methods in CoffeeBackend
        for more explanation (and to remind yourself of the exact workflow name and role name you
        have chosen).
        
        Editing the Second Line of Code
        -------------------------------
        To fix the second line of code you need to replace "TaskName" with the actual name
        you gave this task in CoffeeBackend.  Again, this is so WMP knows not only which workflow
        and which role, but which task is associated with this application.
        
        There are a couple of other important parts of this second line which
        we have already taken care of, but which are worth taking note of:
        
        First important part:
        
        The method called in this line of code is register_source_step.  This is one of three
        "flavors" of method which can be used when initializing a user interface.  A *source* step
        is a user interface that is used to initiate a workflow.  For example, the first step
        in the coffee workflow is taking the drink order.  A *sink* step refers to a step that is 
        the last step in a workflow.  For example, in our simple workflow, preparing the drink
        is actually the last step and so BaristaApplication will use register_sink_step.  When you get
        the application running you will notice that the user interface for a sink step is actually
        different than for a source step because it needs to show you a list of open orders.  That is why
        a different method is used.  Finally, a *transition* step is an application that shows up
        somewhere in the middle of a workflow.  (The coffee workflow is so simple that it has no
        transition steps.)
        
        Second important part:
        
        The second parameter of register_source_step specifies which method contains the
        code to build the user interface for this application.  In this case the method
        is take_drink_order_form_creator, which, as its name suggests, handles the creation
        of the drink order form (i.e. the user interface).  We'll be working on that method next.
        '''
        super(OrderTakerApplication, self).__init__("WorkflowName", "RoleName") # use actual work flow name and role name
        self.register_source_step("TaskName", self.take_drink_order_form_creator) # use actual name for this task

    def take_drink_order_form_creator(self, stepname, form):
        '''
        This method does the actual work of building the user interface.
        Unlike earlier labs where we use print and raw_input to communicate with the user,
        here we are going to have a graphical user interface (GUI) which includes fields
        the user can fill in, static text, and possibly other fancy things like buttons
        and drop down lists.  WMP gives you a kind of "user interface language" which you
        can use to tell it which of these elements to include in the user interface.
        
        for now we will focus on just two of the user interface elements:  fields and static labels.  (the complete
        set can be found in frontend/form.py and documentation will be provided
        as part of Lab 6).
        
        the user interface itself is referred to as a form, a special object
        created by WMP.  interface elements are added to a form by issuing commands
        that look like this:
        
        form.add_static_label(parameters)
        form.add_field(parameters)
        
        and so on
        
        all user interface elements are displayed on the form in the order in which they are
        added.
        
        Static Labels
        -------------
        a "static label" element is any fixed text you may want to add to the form.  typically
        this is used to add instructions to the user.
        
        to add a static label, include a line of code that looks like this:
        
        form.add_static_label('text you want to include')
        
        For Lab 5:  a static label has been included below but the text is not very
        relevant to the user.  Please modify the text to something more appropriate
        to this application.  Feel free to add any additional static labels you think
        are useful as you build this form.
        
        Fields
        ------
        A field is any kind of information you want to collect from the user, including
        text, numbers, dates, and so on.  WMP takes care of adding the appropriate elements
        to the user interface and handling user actions like clicking into and out of
        various fields on the form.
        
        the exact code to use for a field depends on the kind of field.  for example, to
        add a field for a bit of text like a name (or a drink description) add the following:
        
        form.add_field(Type.SHORTSTRING, "FieldName")
        
        Type.SHORTSTRING is used to specify that this is a text field (yes, there is a LONGSTRING
        which we will get to in a moment).
        
        the second parameter is the name WMP will use for this field.  You should not use
        any spaces or special characters in this name.  For example, you might have a field
        name like 'FirstName'.
        
        You can add several other kinds of fields by replacing SHORTSTRING with another field
        type, although you are free to just use SHORTSTRING for this lab.
        
        For Lab 5:  you need to add at least two fields to this form.  One should be to 
        capture the customer's name.  The other should be to describe the drink which
        the Barista needs to prepare.  These can both be of type SHORTSTRING as described
        above.
        
        Optionally you can add more fields and static labels and can even use different
        types of fields (numbers, dates, etc.).  This additional information is described
        below, but you do not need to read through it or add these additional features.
        
        Additional Fields and Options
        -----------------------------
        As noted above, adding additional types of fields or using these
        other options is not required for Lab 5, but you are welcome to experiment.
        
        Some additional options are available for all kinds of fields.  They are
        illustrated in the following line of code:
        
        form.add_field(Type.SHORTSTRING, "FieldName", labeltext="Field Label", initial="default")
        
        You can specify a label to use on the form for any field.  If you omit this parameter
        then the FieldName is used, but sometimes it is nice to have a more user friendly
        label on the form itself.  For example, if the field name is "CustomerName" you might
        want the label used to actually be "Customer Name" since that has a more familiar
        look than two words with no space between them.
        
        You can also specify an initial value to use for the field.  This default value
        will be used if the user does not change it.
        
        Other types of fields (besides text) can be added to a form by replacing SHORTSTRING
        with one of the following:
        
        INTEGER will create a field that only allows integer values.
        
        CURRENCY will create a field formatted for U.S. currency.  Internationalization is
        on our to do list.
        
        DATE will add a date field.
        
        BOOLEAN will add a yes/no checkbox.  (Why 'Boolean' you may ask?  In honor of
        George Boole, a logician who made important contributions to logic and thus
        computer science.  Logic as in TRUE v. FALSE or YES v. NO, just like our checkbox.)
        
        FLOAT will add a number that includes a decimal point (a "floating point"
        number).  You can specify how many digits should be included after
        the decimal point by including the digits parameter as follows:
        
        form.add_field(Type.FLOAT, "FieldName", digits=4)
        
        The default number of digits (if you omit the digits parameter) is 2.
        
        Note also that the parameters with names (digits=, labeltext=, initial=) can be entered
        in any combination and any order.
        
        LONGSTRING is for longer text fields.  The principle difference is that WMP will create
        a multi-line text entry box for a LONGSTRING type field.
        
        CHOICE will create a dropdown box listing a predefined set of options.  The options
        need to be specified in an additional named parameter using the following format:
        
        form.add_field(Type.CHOICE, "FieldName", choices=['first', 'second', 'third'])
        
        You can have as few or many choices as you want as long as choices are in quotes
        and separated by commas inside square brackets as in the above example.
        '''
        form.add_static_label('You are supposed to do something here, I think:') # improve this text!
        # add at least two fields here, along with any additional static labels you need

'''
As with CoffeeBackend, this is the part of the file where we actually
use the code we just wrote.  The first line starts up the OrderTakerApplication.
The second line tells the new application that it should start interacting with the user.
'''    
if __name__ == '__main__':
    app = OrderTakerApplication()
    app.MainLoop()